調査委員会は、この問題は、テストによって事前に確認されるべきだったとしている。しかし、容量見積りの正しさは、テストでは確認できない。設計レビュー時に、議論され、責任を明確化すべき問題である。設計レビューが十分に機能していなかったと言わざるをえない。この設計レビューが形式化し易い問題は、日本のソフトウェア開発組織に共通する問題でもある。設計問題の責任の所在が明確でない日本社会の制度上の問題でもある。また、テストで確認できるのは、容量の限界を超えた要求が発生したとき、異状処理が起動され、システムの障害を未然に防止するよう、要求の受付を制限する機能が正しく働くかどうかなどである。容量超過のリスクについては、稼働直前に認識されていたとの報告があり、その認知されたリスクがどのような手順で処理されたのかも、問題である。調査委員会は、これを「作業場のミス」と呼んでいるが、明らかにリスク管理の手順が未整備であったことも示す事例である。

特に、日本社会では、実践として要求仕様書を作成しない例がしばしば見られる。容量の見積りや、処理性能に関する制約などは、本来、要求仕様書の策定段階で決められなければならない。日本社会の実践では、その見積りを行える人材がユーザ組織に少なく、結果としてベンダー側の技術者が「実現可能な数字」を提示して、ユーザ側の責任者がそれを承認するやり方が採られる例が多い。このため、システムの処理容量量や処理性能は、ピーク時の負荷に耐えられないことがしばしば発生している。この問題を未然に防ぐためには、プロジェクト全体のプロセスを監視する機構が働いていること、特に、設計レビュー時に、処理容量の目標値が現実に達成可能であることを検証しておかなければならない。この検証作業についても、日本社会には、そのような検証を実施できる人材が極端に少ないことが問題である。